\section{Project Management}

\subsection{Project Plan}

The initial project plan was not changed much during the project. The only task that was postponed from the first cycle to the second cycle was testing the performance of DataTurbine \cite{OSDT}. During the first cycle, we realized that it takes more time than expected to set up the DataTurbine and connect a data producer, which sends the data. Therefore the time in the beginning of the projet was rather used to evaluate the features of the software. For the performance tests we needed a data produces, which should be the prototype of our sal-DataTurbine connector. We did not have it at that time, so we decided to do performace measuring at the end of the second cycle with real data out of SAL \cite{SAL}.

There were no further changes to the initial project plan and we were able to fulfill all functional requirements as outlined in \autoref{reqs}.

\subsection{Risks}

The identified risks from the beginning of the project did change a little during the project. While the ``requirement understanding`` could be set down to medium the ''project scope`` got a more severe. During the project it turned out, that the scope of the resulting software could be extended a lot. What we did, was to stick on the requirements, which were agreed with the customers in the beginning of the project. Some features which would be important to have in the software product were explained to be still open at the final project presentation to the customer. But as they were not formally required they are not part of our resulting software product. In  \autoref{potimprovements} the potential improvements are described.





